\documentclass[a4paper,10pt]{article}
\usepackage[spanish]{babel} % Paquetes de idioma
\usepackage[latin1]{inputenc} % Paquetes de idioma
\usepackage{graphicx} % Paquete para ingresar gráficos
\usepackage{grffile}
\usepackage{hyperref}
\usepackage{fancybox}
\usepackage{amsmath}
\usepackage{listings}
\usepackage{color}
\usepackage[a4paper,scale={0.8,0.8}]{geometry}

% Encabezado y Pié de página
\input{EncabezadoyPie.tex}
% Carátula del Trabajo
\title{\input{Portada.tex}}

\begin{document}
	\maketitle % Hace que el título anterior sea el principal del documento
	\newpage

	\tableofcontents % Esta línea genera un indice a partir de las secciones y subsecciones creadas en el documento
	\newpage

	\section{An\'alisis del problema}
		El presente trabajo consiste en el desarrollo de una aplicaci\'on {\it concurrente} que permita la simulaci\'on del control de tres ascensores de un 
		edificio.\\
		\indent Dicha aplicaci\'on deber\'a ser desarrollada en lenguaje C o C++ y funcionar en una \'unica computadora bajo ambiente Unix/Linux.\\
		\indent Dado que el objetivo es que el resultado de la simulaci\'on se parezca lo mayor posible a la realidad, se deben recibir como par\'ametros ciertas 
		caracter\'isticas del ascensor:
			\begin{itemize}
			 \item La cantidad de pisos del edificio.
			 \item La velocidad de desplazamiento del ascensor.
			 \item La capacidad (en cantidad de personas) del ascensor
			\end{itemize}
		Adem\'as de lo anteriormente mencionado, la aplicaci\'on debe recibir el tiempo durante el cual se desea que se ejecute la simulaci\'on.\\
		\indent La interfaz gr\'afica solo mostrar\'a en pantalla sucesos b\'asicos del programa. El resultado detallado de la simulaci\'on se almacenar\'a en un archivo de Log bajo el nombre 
		\textquotedblleft {\it Log\textless fecha\textgreater\textless hora\textgreater.txt} \textquotedblright, en el cual quedar\'an registradas todas las acciones llevadas a cabo por los 
		diferentes procesos.
		
		\vspace{0.5cm}
		
		\newpage
		\subsection {Casos de uso}
			\subsubsection {Diagrama de Casos de uso}
				\begin{figure}[!htpb]
					\centering
					\includegraphics[width=11cm]{Casos de uso/casosDeUso.png}
					\caption{Diagrama de Casos de Uso}
				\end{figure}
				
			\subsubsection {Documentaci\'on de Actores}
			\begin{itemize}
					\item \textbf{Persona:} Son los usuarios que llegan aleatoriamente a los diferentes pisos con la intenci\'on de utilizar un ascensor. Su 
					interacci\'on con el mismo se limita a realizar un pedido, y a cambiar dicho pedido una vez adentro del ascensor.
					\item \textbf{Controlador:} Es la entidad encargada de recibir los pedidos por parte de los pisos. A medida que le llegan las llamadas le consulta
					a cada ascensor la ubicaci\'on y el estado y determina a cu\'al de los tres le pasa la llamada para que sea cumplida.
					\item \textbf{Ascensor:} En este contexto, se utiliza al ascensor como el encargado de transportar entre los diferentes pisos a las 
					personas que lo requieran. Recibe los pedidos por parte del controlador, y a las personas por parte del piso.
					\item \textbf{Terminador:} El actor \textquotedblleft Terminador \textquotedblright  tomar\'ia el rol del tiempo en el sistema, puesto que es 
					el encargado de una vez finalizado el tiempo de simulaci\'on, detener a todos los procesos que participan en la misma.
			\end{itemize}
			\subsubsection {Documentaci\'on de Casos de uso}
			\indent A continuaci\'on se procede a especificar los casos de uso mostrados en el diagrama anterior. Dado que la magnitud del sistema desarrollado no presenta
			casos de uso muy complicados, se omitir\'an los Subflujos y los Flujos de Excepci\'on a menos que se especifiquen explicitamente. 
			\begin{enumerate}
				\item \textbf{Solicitar Ascensor:} Permite a la persona indicarle al ascensor que desea subirse al mismo.\\
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							Debe haber un ascensor funcionando, el controlador debe estar a la escucha de nuevos
							pedidos y el tiempo de simulaci\'on no debe haber terminado.\\
						\item \textbf{Flujo principal:}\\
							El piso crea una nueva persona.\\
							Se genera una lamada para dicha persona.\\
							Se agrega la llamada a la cola de llamadas.\\
							Se coloca a la persona en la cola especificando en el tipo de mensaje si desea subir o bajar.\\
					\end{itemize}
				\item \textbf{Subir al Ascensor:} 
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							Se debe haber realizado una llamada al ascensor previamente.\\
						\item \textbf{Flujo principal:}\\
							El ascensor llega al piso en cuestion.\\
							Si la capaciad llego a su limite (S1).\\
							Si no (S2).\\
						\item \textbf{Subflujos:}\\
							S1: El ascensor evita que ingrese la persona y acola el pedido nuevamente para resolverlo en el futuro.\\
							S2: La persona ingresa al ascensor y modifica su pedido para indicar a que piso se dirije.
					\end{itemize}
				\item \textbf{Realizar Llamada:} 
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							Debe haber un ascensor funcionando.\\
						\item \textbf{Flujo principal:}\\
							El controlador coloca la informaci\'on de la llamada en la cola de mensajes del ascensor.\\
							Una vez colocada la informaci\'on le avisa al ascensor del nuevo pedido por medio de una se\~nal.\\
							Una vez realizada la llamada, el controlador vuelve a quedar a la escucha de nuevos pedidos.\\
					\end{itemize}
				\item \textbf{Consultar estado:} 
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							Debe haber un ascensor funcionando.\\
						\item \textbf{Flujo principal:}\\
							El controlador env\'ia una se\~nal a todos los ascensores solicitandoles el estado.\\
							El ascensor escribe en la cola de mensajes su estado.\\
							El controlador lee el estado, calcula la m\'etrica y decide a que ascensor le enviar\'a el pedido.\\
					\end{itemize}

				\item \textbf{Resolver Pedido:} 
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							Una persona debe haber llegado a un piso, y el mismo debe haber generado un pedido.\\
						\item \textbf{Flujo principal:}\\
							El ascensor llega al piso que gener\'o el pedido.\\
							Se bajan todas aquellas personas que viajaban hasta ese piso.\\
							Mientras puedan ingresar personas, ingresan aquellas que les corresponde (es decir las que desean viajar 
							en la misma direcci\'on que lo hace el ascensor). \\
							Si quedan personas en el piso y se alcanzo la capacidad m\'axima (S1).\\
							El ascensor continua resolviendo los pedidos.\\
						\item \textbf{Subflujos:}\\
							S1: Se deja a la persona esperando, y se reacomoda su pedido para ser tratado en el futuro.\\
					\end{itemize}
				\item \textbf{Finalizar simulaci\'on:} 
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							En este caso no existe ning\'una precondici\'on, el Terminador puede finalizar la ejecuci\'on porque 
							termin\'o el tiempo de simulaci\'on o porque ocurri\'o alg\'un error durante la misma.\\
						\item \textbf{Flujo principal:}\\
							El Terminador le envia una se\~nal a todos los procesos que intervienen en la simulaci\'on para que terminen sus
							ejecuciones de forma ordenada.\\
					\end{itemize}
			\end{enumerate}
			
			
		

	\section{An\'alisis de la Soluci\'on}
		\subsection{Divisi\'on del programa en procesos}
			Para la divisi\'on de los procesos se tuvo en cuenta el comportamiento real de un ascensor:
			\begin{itemize}
				\item \textbf{Ascensor:} Es el proceso que se encaga de simular el movimiento del ascensor. Para ello cuenta con una lista de pedidos en la 
				cual se encuentran tanto los pedidos externos que se le hacen al ascensor, asi como tambi\'en, los pedidos que realizan las personas que 
				ingresan al mismo. Cuando dicha lista este vac\'ia, el proceso quedar\'a a la espera de nuevos pedidos.
				\item \textbf{Controlador:} En este caso, el proceso se encarga de la comunicaci\'on entre los \emph{ascensores} y los distintos \emph{pisos}. 
				Cuando una nueva persona solicita al ascensor, es el proceso controlador el que detecta dicha llegada y le avisa alguno de los ascensores
				del nuevo pedido. 
				Al igual que el caso anterior, este proceso quedar\'a siempre a la escucha de nuevas solicitudes.
				\item \textbf{Piso:} Como se mencion\'o anteriormente, para la divisi\'on de procesos se tuvo en cuenta el comportamiento real de un ascensor, 
				en el mismo, la llegada de personas a cada piso es independiente del resto de los pisos y por lo tanto no deber\'ia haber relaci\'on alguna 
				entre los mismos. Para simular esto se utilizar\'a un proceso por cada piso del edificio que regule el comportamiento del mismo. Dicho proceso 
				se encargar\'a de las llegadas aleatorias de personas que requieran el ascensor. Mediante esta soluci\'on el principal logro que se obtuvo es
				permitir que dos personas lleguen en el mismo instante de tiempo a pisos diferentes, sin que ninguna sea condicionada en su llegada por la otra.
				\item \textbf{Terminador:} Este proceso es el principal de la aplicaci\'on y es el que se lanza cuando la misma se ejecuta. Todos los demas 
				procesos son lanzados por este. Una vez creados todos los objetos y lanzados todos los procesos, el terminador queda suspendido el tiempo que 
				se indic\'o que debe durar la simulaci\'on. Una vez transcurrido dicho intervalo de tiempo, el proceso \emph{terminador} debe finalizar la 
				ejecuci\'on de todo el resto de los procesos creados.
			\end{itemize}

		\subsection{Esquema de comunicaci\'on entre procesos}
			A continuaci\'on se detalla como es la comunicaci\'on entre los diferentes procesos mencionados en el item anterior:
			\begin{itemize}
				\item \textbf{Comunicaci\'on entre el piso y el controlador:}\\
						Cada piso, cada un intervalo aleatorio de tiempo crea una nueva persona, la cual desea ingresar al ascensor. Cuendo esto sucede
						se le debe indicar al mismo que un piso lo requiere. El encargado de dicha comunicaci\'on es el controlador. Es decir que con 
						cada nueva persona que arriba a un piso, se le informa (mediante alg\'un mecanismo que se indicar\'a mas adelante) al controlador
						que en un piso determinado realiz\'o un pedido. En este caso, la \'unica informaci\'on que se intercambia es el n\'umero de piso que
						realizo el pedido, y si la persona que lo realiz\'o desea ir a un piso arriba o abajo del actual.
				\item \textbf{Comunicaci\'on entre el controlador y el ascensor:}\\	
						Cuando el controlador detecta que a un piso arrib\'o una nueva persona, este consulta a los ascensores su estado y ubicaci\'on,  
						elige uno de ellos seg\'un el piso de origen de la llamada y le indica que debe acolar un nuevo pedido a resolver. 
				\item \textbf{Comunicaci\'on entre el ascensor y el piso:}\\
						Al llegar a un determinado piso, el ascensor debe obtener del mismo las personas que lo requirieron en dicho piso. La informaci\'on 
						que intercambian ambos procesos es precisamente las personas que se encontraban en el piso a la espera del ascensor.
				\item \textbf{Comunicaci\'on entre el terminador y el piso:}\\
						Una vez que la simulaci\'on deba finalizar, el terminador comienza avis\'andole a todos los pisos que el ascensor ya no puede recibir 
						m\'as solicitudes, y por lo tanto deben finalizar su ejecuci\'on. Dado que el terminador solo le indica al piso que debe finalizar, no 
						existe ning\'un intercambio de datos en este caso.
				\item \textbf{Comunicaci\'on entre el piso y el controlador:}\\
						Una vez que los pisos han sido destruidos por acci\'on del terminador, este le avisa al controlador mediante una se\~nal que debe
						finalizar su ejecuci\'on.
				\item \textbf{Comunicaci\'on entre el terminador y el ascensor:}\\
						Al igual que el caso anterior, una vez que el terminador le indic\'o a todos los pisos y al controlador que deben finalizar su 
						ejecuci\'on, debe hacer lo propio con los ascensores, para que estos dejen de aceptar nuevos pedidos, y terminen los pedidos que 
						ten\'ian acolados.
			\end{itemize}

		\subsection{Mapeo de la comunicaci\'on en los problemas conocidos de concurrencia}
			La idea de esta secci\'on es la de buscar alguna relaci\'on entre los problemas comunes de la concurrencia vistos en clase y los problemas que se plantearon 
			en el desarrollo del trabajo.\\
			\indent Para comenzar, se enuncian brevemente los problemas conocidos de concurrencia:\\
			\begin{itemize}
				\item \textbf{Fil\'osofos comensales:} Este problema, fue planteado originalmente por Edsger Dijkstra en el a\~no 1965 y es como sigue. Cinco 
					fil\'osofos se sientan alrededor de una mesa y pasan su vida cenando y pensando. Cada fil\'osofo tiene un plato de fideos y un tenedor a la izquierda 
					de su plato. Para comer los fideos son necesarios dos tenedores y cada fil\'osofo s\'olo puede tomar los que est\'an a su izquierda y derecha. Si 
					cualquier fil\'osofo toma un tenedor y el otro est\'a ocupado, se quedar\'a esperando, hasta que se libere el otro tenedor, para luego empezar a comer. 
					Si dos fil\'osofos adyacentes intentan tomar el mismo tenedor a la vez, se produce una condici\'on de carrera: ambos compiten por tomar el mismo tenedor,
					y uno de ellos se queda sin comer. Si todos los fil\'osofos toman el tenedor que est\'a a su derecha al mismo tiempo, entonces todos se quedar\'an 
					esperando eternamente, porque alguien debe liberar el tenedor que les falta. Nadie lo har\'a porque todos se encuentran esperando que alguno deje sus 
					tenedores. El problema consiste en encontrar un algoritmo que permita que los fil\'osofos no se mueran de hambre.
				\item \textbf{Productor/Consumidor:} Se tienen dos familias de procesos, una familia de procesos productores, y otra familia de procesos consumidores.
					Se tiene tambi\'en un repositorio, en el cual cualquier productor coloca alg\'un producto y cualquier consumidor lo retira. En la soluci\'on a este 
					problema se deben cumplir las siguientes premisas:\\
					\begin{enumerate}
						\item No se puede consumir lo que no existe.
						\item Al repositorio se accede de a uno.
						\item Se consumen los items en el mismo orden que se producen
					Hay una variante del problema que se da cuando el repositorio es acotado, lo que agrega una nueva premisa:
						\item No se puede producir si no hay lugar en repositorio.
					\end{enumerate}
				\item \textbf{Lector/Escritor:} Es un problema muy parecido al caso anterior (\emph{Productor/Consumidor}), en el cual se asume que el repositorio 
					(en este caso denominado \'area de escritura/lectura) es ilimitado. En este caso las premisas son como se enuncian a continuaci\'on:
					\begin{enumerate}
						\item Todos los lectores pueden ingresar concurrentemente al \'area de lectura, siempre que no haya un escritor escribiendo.
						\item Un escritor puede escribir, siempre que no haya un lector leyendo, u otro escritor escribiendo.
					\end{enumerate}
			\end{itemize}
			\indent A continuaci\'on se muestra en cada caso, con que problema de la concurrencia se mapea la comunicaci\'on entre diferentes procesos:
				\begin{itemize}
					\item \textbf{Comunicaci\'on entre el piso y el controlador:}
					Este primer caso, se trat\'o como si fuera un productor/consumidor, en donde cada uno de los pisos cumple el papel de un productor que 
					deposita pedidos en un buffer, y el controlador cumple el rol de consumidor y lee del buffer.
					\item \textbf{Comunicaci\'on entre el controlador y el ascensor:}
					Al igual que el caso anterior, este problema se trato como si fuera un productor/consumidor, s\'olo que esta vez el controlador tomo el 
					papel de productor, mientras que los ascensores son los consumidores.
					\item \textbf{Comunicaci\'on entre el ascensor y el piso:}
					Como en los dos casos anteriores, la comunicaci\'on entre el ascensor y el piso se compara con un procutor/consumidor. Al igual que entre
					el controlador y el ascensor, se tiene un productor (el piso) y varios consumidores (los ascensores). Sin embargo, a diferencia del primer caso, 
					ahora se tiene un repositorio diferente por cada productor, mientras que antes todos los pisos utilizaban el mismo repositorio, ahora cada
					uno de los pisos cuenta con un buffer particular que comparte con los 3 ascensores. 
					\item \textbf{Comunicaci\'on entre el terminador y el piso}
					\item \textbf{Comunicaci\'on entre el terminador y el controlador}
					\item \textbf{Comunicaci\'on entre el terminador y el ascensor}\\
					\\En estos \'ultimos tres casos, dado que la comunicaci\'on no requiere intercambio de informaci\'on especifica (si no que solo se realizan 
					avisos de finalizaci\'on), no fue necesario encontrar una soluci\'on m\'as elaborada que los mecanismos de concurrencia b\'asicos conocidos, 
					como los son, las se\~nales.
				\end{itemize}
				
		\subsection{Mecanismos de concurrencia utilizados}
			Una vez analizado todo el dise\~no de la soluci\'on, asi como tambi\'en los procesos que incluye, y la comunicaci\'on entre los mismos, vamos a enunciar y
			justificar el por qu\'e de los mecanismos de concurrencia elegidos.
			
			Por un lado, se debe resolver el intercambio de datos entre los procesos (utilizando por ejemplo memorias compartidas, pipes, o colas de mensajes), por otro, se 
			debe analizar la forma de sincronizar el acceso a dichos datos, asi como tambi\'en sincronizar a los procesos mismos, evitando por ejemplo que un padre finalice
			su ejecuci\'on antes que un hijo, (utilizando sem\'aforos, locks, etc), y por \'ultimo, se debe buscar la forma de comunicar a los procesos, de forma tal que 
			puedan intercambiar alg\'un tipo de mensaje (utilizando en este caso se\~nales o cola de mensajes).
			
			A continuaci\'on se enuncia para cada tipo de comunicaci\'on entre los diferentes procesos, los mecanismos utilizados para comunicar, sincronizar e 
			intercambiar informaci\'on.
			\begin{itemize}
				\item \textbf{Comunicaci\'on entre el piso y el controlador:}\\
				Como se mencion\'o a lo largo de este informe, cada un intervalo aleatorio de tiempo, en cada piso se crea una persona, simulando la llegada de la
				misma a alguno de los ascensores. Adem\'as, como la idea es simular la realidad, no se pod\'ia restringir de ninguna forma, de que en pisos diferentes,
				lleguen en el mismo instante de tiempo personas diferentes.
				Otro punto a considerar es que como se cuenta con tres ascensores, es necesario que haya alguien que reciba los pedidos y los distribuya
				de la forma m\'as equitativa posible entre ellos. \\
				Lo que se hizo fue separar en procesos m\'as simples el comportamiento del ascensor, y se creo un nuevo proceso denominado \emph{Controlador}. 
				Mientras que el proceso \emph{Ascensor} se encarga del movimiento del mismo, es el \emph{Controlador}, el encargado de resolver los
				pedidos que le llegan y distribuirlos. Entonces, cada vez que una persona llega a un piso, no le avisa directamente a alguno de los ascensores, 
				si no que lo hace al controlador, y este si es el encargado de elegir y alertar a un ascensor del nuevo pedido.\\
				Es posible que m\'as de un piso, le intente avisar al controlador de un nuevo pedido al mismo tiempo. Es por eso que se opt\'o por no utilizar se\~nales para
				la comunicaci\'on, si no enviar directamente el pedido a trav\'es de una \emph{cola de mensajes}. 
				El comportamiento bloqueante de la cola, hace que de llegar m\'as de un pedido simult\'aneo, solo uno pueda avisarle al controlador, mientras que los dem\'as quedan
				bloqueados esperando que este finalice su tarea. Es decir que los pisos lo \'unico que hacen al crear una nueva persona es pedir el acceso a la cola, y cuando
				se le otorga colocan la informaci\'on pertinente en la misma.\\
				Por otro lado, el controlador debe estar siempre a la escucha de dicha cola, para ir resolviendo los pedidos a medida que se van generando. Si en 
				alg\'un instante de tiempo, se da el caso de que ning\'un piso requiera un ascensor, entonces el controlador queda bloqueado autom\'aticamente en la cola
				esperando a que llegue un nuevo pedido.

				\item \textbf{Comunicaci\'on entre el controlador y los ascensores:}\\
				En el apartado anterior, se describi\'o de qu\'e forma, un piso le avisa al controlador que un nuevo pedido fue realizado. En este caso, se procede a describir
				de que forma, el controlador elige uno de los ascensores y le avisa que lleg\'o un nuevo pedido.\\
				A diferencia del caso anterior, un ascensor no va a estar siempre a la espera de nuevo pedidos (como lo estaba el controlador), si no que siempre va a estar
				resolviendo los pedidos que ya se le hab\'ian realizado.\\
				Como el ascensor no est\'a siempre a la escucha de nuevos pedidos, se debi\'o implementar una forma de avisarle al ascensor que un nuevo pedido se hab\'ia 
				realizado, y ademas brindarle la informaci\'on pertinente a dicho pedido. \\
				Esta vez se opt\'o por utilizar \emph{se\~nales} y \emph{cola de mensajes}.				
				El controlador al recibir un pedido env\'ia una se\~nal a todos los ascensores para que informen la ubicaci\'on en que est\'an y en qu\'e modo se encuentran.
				Todos los ascensores reciben la se\~nal y colocan en una cola de mensajes la respuesta con la informaci\'on solicitada.
				El controlador procede a leer todos los mensajes recibidos, los analiza y calcula una m\'etrica para elegir a cu\'al de todos les enviar\'a el pedido recibido.
				Una vez hecha la elecci\'on el controlador, coloca el pedido en la cola de mensajes y le advierte al ascensor mediante una se\~nal que tiene un pedido nuevo.
				La comunicaci\'on mediante el controlador y los tres ascensores se hace utilizando una sola cola de mensajes, haciendo uso del campo \emph{tipo o mtype} 
				caracter\'istico de las colas de mensajes para seleccionar cu\'al de los ascensores es el destinatario del pedido. \\
				Si al ascensor no le quedan pedidos por resolver, este detiene su ejecuci\'on (pasa a estado dormido/esperando) mediante pause hasta recibir una nueva se\~nal
				que le indique como debe continuar su ejecuci\'on. 
				
				\item \textbf{Comunicaci\'on entre el ascensor y el piso:}\\
				En las dos secciones anteriores se detall\'o la forma en que los pedidos son recibidos. A continuaci\'on se procede a explicar de qu\'e forma son resueltos.\\
				Al recibir un pedido, la informaci\'on que necesita el ascensor es el piso en el cual se realiz\'o el pedido y si el usuario desea subir o bajar en el 
				ascensor. Dicha informaci\'on es enviada a trav\'es de la cola de mensajes de pedidos al controlador y este se la pasa a alg\'un ascensor a trav\'es de 
				otra cola de mensajes. 
				Una vez recibido el pedido, el ascensor lo coloca en su lista de pedidos, y se dirige al pr\'oximo piso que deba visitar. Al llegar al piso,
				se pueden tener dos casos, por un lado, se puede llegar al piso porque una persona desde dentro del ascensor desea bajarse en el piso, o por otro lado, una 
				persona externa desea subirse al ascensor.\\
				En el primer caso, el ascensor desciende a las personas y continua su camino al siguiente pedido de la lista, sin intercambiar informaci\'on con el piso.\\
				En el segundo caso la situaci\'on es m\'as compleja. El ascensor debe llegar al piso, y debe permitir a las personas que lo estaban esperando que entren al 
				mismo, siempre y cuando no se sobrepase la capacidad m\'axima. Para poder brindarle la informaci\'on de las personas al ascensor, nuevamente 
				se opt\'o por la utilizaci\'on de una cola de mensajes. Al llegar una nueva persona al piso, este no solo le avisa al controlador del nuevo pedido, si no que tambi\'en 
				coloca esta persona en la cola de mensajes de comunicaci\'on con el ascensor. Con cada nueva persona que llega al piso, es un nuevo pedido que se le hace al 
				controlador, y una nueva persona que se coloca en la cola de mensajes. Al llegar el ascensor al piso lee de la cola de mensajes, tantas personas como pedidos 
				de ese piso haya recibido, o tantas personas como entren seg\'un la capacidad. En el caso de que no se pueda resolver un pedido por estar sobrepasada la capacidad, dicho
				pedido se deja colocado en la lista de pedidos del ascensor, y la persona no es le\'ida. Al hacer esto, se logra que la pr\'oxima vez que el ascensor
				pase por este piso, puedan ingresar todas las personas que no puedieron hacerlo originalmente.\\
				Finalmente aclarar que la comunicaci\'on entre el ascensor y el piso se realiza mediante una sola cola de mensajes por piso, haciendo uso del campo \emph{mtype}
				para distinguir a las personas que quieren bajar y a las personas que quieren subir. Cuando el ascensor llega al piso, lee solamente el tipo de mensajes que 
				le corresponde de acuerdo al estado que se encuentra el ascensor (subiendo o bajando) y el pedido que fue realizado.
				
				\item \textbf{Comunicaci\'on entre el terminador y el piso:}\\
				Una vez finalizado el tiempo que debe durar la simulaci\'on, el terminador debe indicarle a los pisos que ya no se pueden recibir m\'as pedidos. Dado que no 
				se requiere ning\'un intercambio de informaci\'on espec\'ifica, en este caso se utilizaron nuevamente las se\~nales para llevar a cabo el objetivo.\\
				Cuando se terminan de crear todos los procesos, el terminador pasa a dormir el tiempo que se indic\'o por par\'ametro en la aplicaci\'on, al finalizar dicho
				intervalo de tiempo, el terminador se despierta y le manda una se\~nal a cada uno de los pisos para que estos dejen de generar pedidos y finalicen su 
				ejecuci\'on de forma ordenada.
				
				\item \textbf{Comunicaci\'on entre el terminador y el controlador:}\\
 				De forma similar a la anterior, luego de que los pisos hayan sido destruidos, el terminador le env\'ia una se\~nal al controlador para que este deje de escuchar 
				nuevos pedidos.
				
				\item \textbf{Comunicaci\'on entre el terminador y los ascensores:}\\
				Una vez terminada la ejecuci\'on de todos los pisos (y por lo tanto tambi\'en la del controlador), solo queda finalizar los procesos que controlan los ascensores.\\
				Para ello, nuevamente el terminador le env\'ia una se\~nal a todos los procesos para que termine su ejecuci\'on de forma ordenada. Sin embargo, en este caso, cada 
				ascensor al recibir la se\~nal, debe resolver todos los pedidos que le quedaban pendientes antes de terminar su ejecuci\'on.
			\end{itemize}

		\subsection{Logger}
			\indent Uno de los requerimientos no funcionales de la aplicaci\'on era la generaci\'on de un registro de todas las operaciones que se llevan a cabo. Dicho 
			registro resulta de gran utilidad a la hora de desarrollar aplicaciones concurrentes en donde seguir la ejecuci\'on del programa presenta una dificultad considerable.\\
			\indent Para generar este archivo de registro se creo una clase encargada de registrar todos los mensajes que se le env\'ian en un \'unico archivo
			denominado \textquotedblleft {\it Log\textless fecha\textgreater\textless hora\textgreater.txt} \textquotedblright, d\'onde \textless fecha\textgreater 
			y \textless hora\textgreater se corresponden con el momento de inicio de la ejecuci\'on del programa. 
			Cada vez que un proceso desea registrar un mensaje, se lo debe indicar a la clase Log, la cual se implement\'o mediante un patr\'on Singleton.\\
			\indent Dado que todos los procesos registran mensajes con el mismo Logger y en el mismo archivo de registro, se debi\'o sincronizar el uso del mismo mediante el uso
			de locks, los cuales evitan que m\'as de un proceso escriban al mismo archivo al mismo tiempo, dando como resultado un mensaje inv\'alido.\\
	
	\newpage
	\section{Diagramas de Clases}

		\subsection{Diagrama de Clases Ascensor}
			\begin{figure}[!htpb]
				\centering
				\includegraphics[width=17cm]{Diagramas de clases/Diagrama de clases.png}
				\caption{Diagrama de Clases Ascensor}
			\end{figure}
		\newpage
		\subsection{Diagrama de Clases Se\~nales}
			\begin{figure}[!htpb]
				\centering
				\includegraphics[width=8cm]{Diagramas de clases/clases seniales.png}
				\caption{Diagrama de Clases Se\~nales}
			\end{figure}
		
		\subsection{Diagrama de Clases Logger}
			\begin{figure}[!htpb]
				\centering
				\includegraphics[width=6cm]{Diagramas de clases/clases Logger.png}
				\caption{Diagrama de Clases Logger}
			\end{figure}
		\newpage
		
	\section{Diagrama de Transici\'on de Estados del Controlador}
		\begin{figure}[!htpb]
			\centering
			\includegraphics[width=16cm,angle=90]{Diagrama de transiciones/diagrama Transiciones.png}
			\caption{Diagrama de Transici\'on de Estados del controlador}
		\end{figure}

	
\end{document}
